This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 
H04L 25/02 



A2 



(11) International Publication Number: WO 99/07121 

(43) International Publication Date: 1 1 February 1999 (11. 02.99) 



(21) Internationa) Application Number: PCT/US98/ 1 5884 

(22) International Filing Date: 28 July 1998 (28.07.98) 



(30) Priority Data: 
60/054,121 



29 July 1997 (29.07.97) 



US 



(71) Applicant: NETADVANTAGE CORPORATION [US/US); 

Suite B. 1674 North Shoreline Boulevard, Mountain View, 
CA 94043-1316 (US). 

(72) Inventor: FET1K, Richard, J.; #4 Comstock Queen Court, 

Mountain View. CA 94043 (US). 

(74) Agents: HOFFMAN, Brian, M. et a!.; Fenwick & West LLP. 
Two Palo Alto Square. Palo Alto, CA 94306 (US). 



(81) Designated States: AL, AM, AT, AU. AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, 
GH, GM, HR, HU, ID, IL, IS, JP, KE. KG, KP, KR, KZ. 
LC, LK, LR, LS, LT. LU, LV, MD, MG, MK. MN, MW, 
MX, NO, NZ. PL, FT, RO, RU, SD, SE, SG. SI, SK. SL, TJ, 
TM, TR, TT, UA, UG, UZ. VN, YU, ZW. ARIPO patent 
(GH, CM, KE, LS. MW. SD. SZ. UG. ZW), Eurasian patent 
(AM, AZ. BY, KG, KZ, MD, RU. TJ. TM), European patent 
(AT, BE. CH. CY, DE. DK. ES. FI. FR. GB. GR. IE, IT. 
LU, MC. NL, PT, SE), OAPI patent (BF. BJ. CF, CG, CI. 
CM. GA, GN. GW, ML, MR. NE, SN, TD. TG). 



Published 

Without international search report and to be republished 
upon receipt of that report. 



(54) Title: METHOD AND SYSTEM FOR CONDUCTING ELECTRONIC COMMERCE TRANSACTIONS 
(57) Abstract 

A system and method for conducting electronic payment transactions accepts and stores information describing an i tern sold by a 
merchant on a commerce server. The merchant also defines payment processing rules that define die payment methods accepted by the 
merchant. The merchant* in turn, is provided with a reference identifying me commerce server and the item. The merchant preferably 
publishes this reference at the merchant's web site on a web page offering the item for sale. A customer viewing the merchant's web site 
indicates a desire to purchase the item by selecting the reference. As a result, the customer is put in contact with the commerce server and 
is provided with information from the commerce server about the item and is given a list of payment options. The customer preferably 
selects a payment option and provides the commerce server with payment information, such as a credit card number. In response, the 
commerce server contacts a selected payment system and completes the electronic com mercc transaction. The commerce server then notifies 
the customer and the merchant of the results of the electronic commerce transaction and delivers the item to the customer. 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used lo identify States party to the PCT oh the f^t pages of pamphlets publishing intentional applkations uhdcT the PCT. 



AL 
AM 




ES 


Spain 


. LS 


Lesotho 




FI 


Finland 


.ix 




AT 




>R 


France . 


MM 


Luxembourg 


AU 


Austrafia 


GA 


■'. Gabon 


XV 


•• ;.':.Latvla ■■ 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 




BA 
BB 


Bosnia end rfcrcegovina 
Barbados 


CB 
GH 


Georgia 
Ghana 


MD 

MG 


•*:*;■ Republic of Moldova 
Madagascar . 


BE . 


Belgium 


CN 


; - Guinea 


MK 


The former Yugoslav : 


BF 

BC 


Burkina Faso 


GR 
HU 






Republic of Macedonia 
May 


Bent*"* 


Hungary 


* s 'ml v " 


BJ 




IE 


Ireland 


"MN 


Mongolia 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


BY 


Belarus 


IS 




MW 


Malawi 


CA 


Canada 


IT 


Itary 


MX 


■ Mexico 


CF 


Central African Republic 
Congo 


JF 


- 


NB 


^«ger 


CC 


KB 




NL 


. Netherlands' . 


<CH 


Switzerland 
CV*e d'tvoire 


KG 


':' Kjrrgyjestan 


NO 


Norway -.- 


CI 


KP 


Democratic People** . 


NZ 


Ne w Zealand 


CM 


.Cameroon 




Repobhc of Korea 


PL 


■ Poland ■ 


CN 


China 


KR 


Republic of Korea 
Kazakstan 


FT 




CU 


Cuba 


kz 


RO 




cz 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation . 


DB 


. Germany 


■ LI - 


Liechtenstein' 


SD 


Sudan 


DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden _ 


EE 


Estonia 


LR 


Liberia 


SG 



SI 
SK 
SN 
SZ 
TD 
TC 
TJ 
TM 
J.TR _ 
TT 
UA 
UC 
US 

uz 

VN 
YU 
ZW 



Slovenia 



;'.,Cbad 
.Togo. 
TajaJsian 



-.3X"c*cy_,.,.,,...._ : ^.,^:. 

Trinidad and Tobago 



Uganda 



Uzbekistan 
Viet Nam 
Yagbslavia 
Zimbabwe 



WO 99/07121 



PCT/US98/15884 



the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify ' 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment . 
in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 
convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 
and veriflably perform inventory, sales, arid delivery tracking arid transparently support 
different types of payrnents and currencies. 

Summary of the Invention 
The above needs are met by a method and sy stern for conducting electronic commerce 
transactions that allows a merchant to easily sell a mix of physical and intangible items arid 
supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic comirierce with other merchants arid : 
-vendors.--' - ■ . w"" -. ...... ,\.v V*' : ": -~ ; - : '- 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the comriierce server. Then, the 
merchant provides the commerce server with information about an item sold by toe merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with ah online 
game. The merchant also provides me conmierce server with other attributes of me iterii frorri 
which the customer iriay select, for example, the quantity or duration of an iterii: In addition^' 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed arid 7 
when or how often to bill the customer. 
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The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard * 
good, soft good, or online good depending upon the delivery options available for the item. 
The commerce server, in addition, provides the merchant with a "payment button" including a 
5 universal resource locator ("URL'*) that points to the commerce server and includes 

information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the payment button on the 
merchant *s web site. 

The customer selects the payment button when the customer wishes to purchase the 

1 0 associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web server 
with the payment information necessary to complete the transaction. 

15 When the merchant's payment terms specify that payment is required, the commerce 

server preferably identifies the remote payment system selected by the customer and contacts it 
to Complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 

20 into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, i f appropriate, 
delivers the item using one of the delivery options speci fied in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 

25 an item to be purchased by the customer, receiving payment information specifying a payment 
; method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of me payment transactibn. 

Similarly, computer program instructions for conducting electronic commerce 

36 transactions in accordance with the present invention include instructions for storing item 
• : information received from the; merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to ah embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
10 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, arid payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
.15 . . information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an oMer confirmation web page. 

Detailed Description of the Preferred Embodiment 
As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL**) is a reference to a 
piece of information or software function On a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages'* are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses externa] programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, me present is not limited to the 

Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Intemet-based equivalents 
,3Q for communicating between the various entities described herein, 
r FIG. 1 is a W 

to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as **the customer *) 1 1 6, a merchant web server (sometimes referred to as "the 
merchant**) 1 1 2, and a commerce server ("CS") 114, all coupled to the Internet 1 16 In a 
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typical embodiment, the customer computer 1 10 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 1 0 is 
coupled to the Internet 116 via a network connection 118. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 
5 modern utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR®, preferably executes on the client computer and sends data from the client 
computer 1 10 to the merchant web server 1 12 via the network connection 1 18 and Internet 
116. In another embodiment, the customer computer 1 10 is a palm-top device or personal 
10 digital system communicating via radio waves with the Internet 1 1 6 or another electronic 
• corhnierce system. '." 

The merchant web server 1 1 2 is preferably similar to the customer computer 110 except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous custom^ 

15 information, intellectual property, and/or services via a web site hosted on the merchant web 
server 112. The merchant's 1 12 web site may, for example, display a catalog of software 
a^vMlable for purchase, allow the customer 110 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 
a database of information. 

20 As used herein, the terms "customer*' and "merchant" depend upon the specific 

transaction being conducted. In a chain of commerce transactions, the "customer" in a first 
transaction may be a "merchant** in a second transaction. F6 customer 1 10 may 

buy components of a product from vendors or merchants 1 12 using the 

electronic commerce system described herein and A product via 

%*. - 1 25 the customer's own web site and the CS 1 1 4. 

• : The merchant's web site displays at least one payment button." A payment button is a 
graphic button, a region of a larger o f URL link which 

the customer 1 10 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Intemet-based 

30 electronic commerce system. In such a^ payment button is considered to be 

below, the payment button is pr^ the customer 1 10 when the customer 1 10 wishes to 
purchase and pay for an ite^ web site^ In a preferred 

embodiment, every type of iterrt for sale on the merchant's web site ha^ a separate payment 
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button. When a customer 110 wishes to purchase the product, the 110 customer presses the 
produces associated payment button. Then, the customer 1 10 is preferably presented with a * 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 1 0 to identify a specific product or an attribute of a 
product, like color, that the customer 1 1 6 wishes to purchase. 
10 Every payment button has an associated URL that points to information in the CS 1 14. 

Inferably; a database key that uniquely identifies the merchant 1 1 2 and/or item for sale is 
encoded within the URL When the customer 1 1 0 presses the payment button, the customer 
1 10 is redirected to a web page provided by the CS 1 14 arid specific to the merchant 112 
and/or iterii. 

1 5 In one embodiment, .the CS 114 queries the customer for the quantity or duration of the 

item that the customer 110 wishes to purchase and payment information The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processmg rules arid delivery options 112. The CS 114 

records the transaction in its database and notifies the customer arid merchant whether the 
20 transaction was successful. Accordingly, the merchant 112 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110 

FIG. 2 is a high-leVel block diagram 1 14 

arid also illustrating a remote pa>roerit systerri 222 arid a rerriote merchant 223 according to a 
preferred embod 

25 % customer 1 10 arid merchant 1 12 computers, except that theCS 114 has enough processing 

power and internet 116 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 114 described herein may be performed by 
hardware or software modules within the CS 1 14 In one embodiment Of the present invention, 
the functionality of the CS 1 1 4 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-coriipatible hardware under control of MICROSOFT 

another embodiment of the present invention, the functionality of the CS 114 is provided by a 
distnbuted computing system as described below 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which* in * 
turn, typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
5 CYBERGASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 114 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 1 6 or a dedicated secure 
link. Each payment system has an applications programming interface ("APT*)- By using the 
API, the CS 114 communicates with the payment system 222 and performs secure and 
10 verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchaht 223 is included in FIG. 2 to illustrate that the customer's 
15 i 10 electronic commerce transaction performed t>y the CS 114 may contact a remote payment 
system 222 and/of a remote merchant 223 > 

TMCS l 14 includes a payment button tra^ 21 0 which is coupled to a 

database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 21 0. While these functional components are illustrated in FIG 2 as 
20 discrete entities, the CS 114 may be executed on a distributed computer system having a 

plurality of engines, databases, arid web servers working together the perform the functions 
described herein. For example, one embodiment of the CS 114 uses multiple transaction 
engines 210 arid web seivera 2 14 and a single distribute database 212, thereby providing 
scalability to the CS 114 The number of web s^ets 214 and transaction engines 210 depends 
25 oil the actual system load and the desire to achieve better performance through balancing the 
: - ; v ^ " "** ' ' - , 

^ The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Prograrnming 
30 Interface C*P APF) module 220 enabling communication between the CS 114 and the remote 

of each payment system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a payment system 222 or merchaht 223 by making 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 arid merchants 223 to be added to the ; 
CS 1 1 4 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store**) 224, in combination with the web server 
214, allows a merchant 112 to obtain a payment button. The web server 214 is preferably an 
10 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
110 and preferably uses industry standard technologies including HyperText Markup Language V: 
("HTML"), and HTTP tb deliver information to the customer 11 0. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 
15 arid the secure sockets layer ("SSL ,, ); to ensure that communications with the customer 110 are - v 
private The firewall 216 allows only aumorized cbrrimumcations between the web server214 
arid the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB stoire 224 allows me me to purchase payment buttbns and add product 

20 descriptions, merchant coiifijguratioris, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 112 accesses the PB store through 
a web site on the web server 214; The PB store module 224 captures the merchant 112 actions A 
on the web server 214 arid creates the appropriate entries in the database 212. 
:i : : ^ In one embodiment of the present invention, the PB store web site'de^cribe^ 

25 payment button mechanism, the services offered by the payment button vendor, arid the costs 
of me services. In addition, the web site preferably has a merchant registration form 226 for 
registermg new merchants, a merchant renewal forrri 228 for renewing merchant registraHons, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 
30 described herein, v. . \ J' '-./\ -.. 

The merchant registration form 226 allows the merchant 1 12 to mput information 
identifying the merchant 112 and includes a payment button with which the merchant 1 12 can < 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued if 
a login/password pair and an account with the CS 1 14 through which the merchant 112 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 

the merchant renewal form 228 preferably includes a payment button with which the merchant 

112 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter item 
5 description data, such as item names and descriptions, prices, types, and delivery options, arid ' 

payment processing rules, such as supported credit cards, payment systems, and currencies. In 

addition, the payment processing rules may rank the payment systems in order of preference, 

describe when payment is required (e.g., the merchant may require billing after 90 days), 

and/or describe the quantity or duration of an item available for a certain price. In one 
1 0 embodiment of the present invention, the merchant 112 enters the item description data and 

payment processing rules by uploading a file to web site having the information in a 

standardized format . 

When entry of this data is completed, the payment button generation form 230 sends 

Ae (data to ^ the information in the database 212 at a 

15 location specified by a key. The trarisach^n engine 210 passes the key back to the PB store . ^ 

Web site, which provides \[f 

results of the payment button generation transaction: If the transaction was successful ^ the 

payment button download page includes the payment button issued to the merchant 1 12. The 

payment button has an associated URL that specifies the key. Accordingly, little or no 
20 engineering effort is required to maintain each merchant configuration on the CS 114. 

In one embodiment of the present invention, there are multiple PB store web sites 

communicating with the database 212 through the transaction I engine 21 0. When a payment : 

button is created, the transaction engine 21 0 creates a field in the database 212 entry specifying 
ui'i^&fJZ. store that generated the payment button. Accordingly, payment buttons may be 
25 "branded*' among different payment button vendors. ^^'fJ**** 

The database 212 is preferably a robust relational database. A preferred embodiment of 
■ , the preseut invention uses the ORACLE 7 database to implement ^ .... j ^ 

herein. The database 212 stores item descriptions, payment processing rules, and om 

information necessary to complete a payment transaction on behalf of a merchant 1 12. This 
30 merchant information is preferably accessed in the database by using a key assigned to each 

mtttimi 1 12 and/or item ^ 212 is also used as k ^ 

mformation including authorization logs, payment status and completion records, and other * f 

information required by the merchant 1 12 and the CS i 14. . 7- ; 
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FIG- 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 1 12. Accordingly, the primary entry 310 is typically 
accessed either when the merchant 112 provides the key while using the PB store web site or 
when the customer 110 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 310 contains a field 318 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 310 also 
contains a field 320 holding item type information as specified by the merchant 1 12. The item 
type information preferably describes the item attributes input by the merchant 1 12. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312,314,316 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, arid 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods arid corripanies available for 
delivering the hard item to the custorner 110- . 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that cart be provided to the customer to effectuate the 
purchase. For exariiple, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 110 computer system. 

. ... An online item is_typ to an online service or^other software executing 

remotely from the customer 110. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 1 1 0 to access the online 
item: For example, the options 326 may provide ' iris rriictions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG, 4 is a flow diagram illustrating the interactions between the custorner 110, 
merchant 1 12, CS 1 14, database 212 arid a payment system 222 when completing a payriient ; 
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transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to . the bottom and horizontal lines represent 
communications between the various entities: FIG. 4 illustrates only major interactions 
between the entities and does not represent every interaction. In addition, FIG. 4 illustrates a 
simple case of the present invention wherein the merchant's 1 1 2 payment processing rules 
specify that the payment transaction should be processed at the time the customer's 110 order 
is received. 

Initially, the customer 1 1 0 is browsing the merchant's web site and decides to purchase 
an item by pressing 410 the associated payment button. In response to the press, the 
merchant's web server 112 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's, browser fetches 414 
the referenced page from the CS 1 14. 

The CS 1 14 parses the URJL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 1 1 0 wishes to purchase. Using this key, the CS 
1 14 accesses 41 <3 the database 212 and dynamically generates a web page indicating the 
attributes and payment options "available for the item as defined by the merchant 112. In 
addition, the CS 1 14 preferably determines the language utilized by the customer 1 10 and 
currencies supported by the merchant 112 and modifies the web page accordingly. This 

. /generated web page is sent 418 to the customer 1 10. FIG. 5 illustrates ah exemplary screen 
display 500 of the web page seeking payment information from the customer 110. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transmits 420 
these data to the CS 1 14. The CS 1 14 stores 422 the received data in the database 212 and 

---:^di&it^ic&^KijEi- ^l^^tod'-|>flryMiiBkit- s^^fienQi ^Ais '<leBiarif>ed 'aAKyvc^ the GS 1 14 preferably uses the 
PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
Communications wife the payment system 222, customer 110, and merchant 1 12 in the _ _ . :1 
database 212. Therefore, the database 212 can be used to iwonstruct transaction histories in 

/ order to provide error tracking and accounting services. If the payment system 222 rejects the 

; transaction,;^ GS : 1 1 4 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG 4), 

If the payment system 222 approves the transaction, the CS dynamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 110 This page preferably contains a receipt or confirmation number generated by 
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the CS 114. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 112 and customer 1 10 to confirm 
5 . . .payment, to query the CS 1 1 4 for payment status information, and to use the CS 1 1 4 to query 
the payment system for account status information. The web page also preferably contains any 
other information required by the merchant 112 and a link to a confirmation page on the 
nierchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of ah order 
confirmation web page. 

10 : v The CS 114 also notifies 428 the merchant 112 that payment was accepted and provides 

the same receipt or confirmation number as was provided to the customer 1 10. In one 
V; ^mbbaimerit, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 1 0 and merchant 112 are notified that the purchase was made. 

Finally, the customer 1 10 fetches 430 the confirmation web page oh the merchant's 
15 . web site, ^ the customer 1 10 with additional information 

about the purchase or any other information which the merchant 1 12 desires to provide 
In summary is a system, method, and computer program 
instructions for conducting electronic commerce transactions via me mtem 
coinmuhicaf ion system. The merchant 112 opens an account on the CS 1 14 and supplies 
20 information about items sold by the merchant 1 12. The CS 114 stores this information in a 
database 212 entry and issues the merchant 1 12 a URL containing the key to database entry 
The merchant 1 1 2 suppHes this URL to customers wishing to purchase an item, causing a 
customer 110 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 110, conducts me electronic cornmen^ transaction with a remote payment system 
; ^ • of the result: 
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Claims 

I claim: 

1. . A computer system for supporting electronic commerce transactions between a 
customer arid a remote merchant, the computer system comprising: * 
5 a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 

system for performing an electronic commerce transaction, the transaction 
-engine comprising: 

10 ■ a first module for receiving ah electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
, a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
15 ; a third module for perfbrriiing the electronic commerce transaction with the 

remote payment system using the payment information received 

from me customer. 

.2. The computer system of claim 1 , wherein the transaction engine further 
■M ■ \ comprises: 

20 a fourth module for notifying the remote merchant and the customer of a result of 

the electronic commerce transaction. 

.... : 3. , The computer system of claim 1 , further comprising: 




the remote merchant and customer; and 
firewall between me web server andmetra^ for sectiring- 



.-. -■■ 4o The computer system of claim 3, wherein the transaction engine further 
comprises: .... ..... " 

a fifth module for dynamically generating a web page from the entry in the database 
30 **£f< and providing the web page to the customer via the web server, the web 

page providing infonhation about the item offered for sale by the remote 
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merchant and facilitating collection of the payment information from the 
. customer. 

5. Tne computer system of claim 3, wherein the computer system further 
• comprises: . 
5 a sixth module for accepting the merchant information identifying the item offered 

- for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and pro viding the remote 
merchant with a reference to the database entry. 

6 The computer system of claim 1, wherein the electronic commerce transaction 
10 identifier is a URL identifying the computer system and including a key to the entry in the 

■.database. 

7. The computer system of claim 1 , wherein the database further comprises 

an entry specifying payment processing rules defined by the remote merchant; and 
. ah entry specifying deli very options for me item ofiered for sale by the remote 
15 merchant* 

8 The computer system of claim 1 , wherein there are a plurality of available 



remote 

/; • payment systems: •/'.' '.' ' *' : 

20 9. - The computer system of claim Vw^ 

a plurality of distributed computer systems. 

... 1 6 A method of conducting electronic com merce be tween a remote cust omer and a 
remote merchant, the method comprising the steps of- - \ 

receiving information identifying an item to be purchased by the remote customer; 
25 receiving payment information specifying a payment method to be used by the 

~: remote customer to purchase the item; : ■ _ 

conducting a payment transaction with a remote payment system specified by the 

payment information; \\ \ T .•■-> 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

M. The method of claim 10, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method 6^ 

providing the remote customer with a list of item attributes from which the 
customer can select? "":V'V 

14. The method of claim ^ 



purchasing the item; and 
receiving delivery options for the item 



15. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 



nputer instructions comprising: , _ . . 

instructions for storing item information received from the remote merchant; 

instructions for issuing the remote merchant a reference to the stored item ^ ; ^ - 

^^^^^ as ^^ df ^ r ___, : • — — : — - — .■ .. — .■■v ,,^ .^^ 



instructions for receiving ah electronic Commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
:{:j'*y; : i isisued to me lernbtem . y:yK--\ ,;'~:,y :^:Sriy : • ci> ;•«••". 

instructions for accepting 

payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 

payment system using the payment information received from the remote * 
. customer. 

16. The computer-readable medium of claim 1 5 / wherein the mstructibhs fiirther ; 
5 comprise: 

instructions for noti fyirig the remote merchant and the remote customer o f a result 
of the electronic commerce transaction. 

17. The computer-readable medium of claim 1 5, wherein the instructions for storing \ 

item in 

10 



i; arid 

instructions for receiving delivery rules from the remote merchant speci fying 
delivery options for me electro 
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